home *** CD-ROM | disk | FTP | other *** search
/ By Popular Request 2.0 / By Popular Request 2.0 (Arsenal Computer).ISO / amiga_5 / pltrej02.lha / PlutReject.doc < prev    next >
Text File  |  1994-10-16  |  10KB  |  262 lines
  1.             ------------------------------------------------
  2.  
  3.                                PlutReject
  4.  
  5.           Utility to bypass receiving a file you already have
  6.  
  7.                        by Peter Deane (3:622/401)
  8.  
  9.                       Version 0.2 16 October 1994
  10.  
  11.                            in GFA BASIC V3.51
  12.  
  13.             ------------------------------------------------
  14.  
  15.  
  16.                               Introduction
  17.                               ============
  18.  
  19.  
  20. In the TRAPDOOR support echo, Mike Hall asked this question:
  21.  
  22.  MH> I've got a few file echo's set up and manually poll for a some of
  23.  MH> them, sometimes I've already got the files and so am wondering is
  24.  MH> there a way to skip the current transfer and not abort the whole
  25.  MH> trapdoor session?  It's painful when calling STD watching a 500k
  26.  MH> file come in when you've allready got it!  :8-/
  27.  
  28.  
  29. Good point, I thought, and supplied Mike with this answer:
  30.  
  31.  
  32.  PD> Hey, it's even worse polling INTERNATIONALLY and having this happen
  33.  PD> as well!
  34.  
  35.  PD> But there IS something you can do about it.  Sit down while I tell you a
  36.  PD> tale of partial files and resuming transfers....
  37.  
  38.  PD> When TrapDoor receives a partial file it renames it.  The filenaming
  39.  PD> scheme used is:
  40.  
  41.  PD>  !.Filename.A.B.C.D
  42.  
  43.  PD> Where "Filename" is the original filename of the file and A.B.C.D
  44.  PD> is the address of the system sending you that file.
  45.  
  46.  PD> For example if you were receiving a file called Foo.lha, from
  47.  PD> 3:622/401 (me) and it was aborted halfway through for some reason
  48.  PD> the filename of the partial file would be:
  49.  
  50.  PD>  !.Foo.lha.3.622.401.0
  51.  
  52.  PD> This partial file would ALSO contain a filenote.  This consists of
  53.  PD> three parts terminated by a semicolon:
  54.  
  55.  PD>  Length 123456; FileName Foo.lha; Time d17089c8;
  56.  
  57.  PD> Okay, so using this information we can fool TrapDoor into resuming
  58.  PD> a file transfer at ANY stage.  What we want to do is for it to
  59.  PD> resume at an offset equal to the length of the file.
  60.  
  61.  PD> Let's assume we have received a file called TD_1_84.lha from a
  62.  PD> system, and now ANOTHER system is also trying to send us that file,
  63.  PD> which we don't want.  Let's also assume the filesize is 300,000
  64.  PD> bytes long, and the address of the system now trying to send it to
  65.  PD> us is 1:234/567.8.
  66.  
  67.  PD> When the other end starts to send us the file, we hangup.  Okay
  68.  PD> what you need to do now is copy the _original_ file into your
  69.  PD> inbound directory.  Use a copy so you can delete it later.  The
  70.  PD> file has to be exactly the right length, BTW
  71.  
  72.  PD> Firstly we rename this temporary file using the above convention:
  73.  
  74.  PD>  Rename TD_1_84.lha as !.TD_1_84.lha.1.234.567.8
  75.  
  76.  PD> Then we need to set the filenote.  We only need the Length and
  77.  PD> Filename fields, the time isn't necessary.
  78.  
  79.  PD> FileNote !.TD_1_84.lha.1.234.567.8 "Length 300000; FileName TD_1_84.lha; "
  80.  
  81.  PD> And with that in the inbound directory we call back.
  82.  
  83.  PD> The result will be "Resuming Transfer from Offset 300000", and
  84.  PD> since 300000 is the actual size of the file, 0 bytes of it will be
  85.  PD> transferred and then the system will send you the next file it has
  86.  PD> for you.
  87.  
  88.  PD> Since the system thinks it has succesfully sent you the file, it
  89.  PD> shouldn't try sending it again (if it was a TrapDoor, a tilde would
  90.  PD> be prepended to the filename in the FLO file).
  91.  
  92.  PD> Regards,
  93.  PD> -Peter!
  94.  
  95.  PD> PS:  TrapDoor will rename our temporary file in inbound to the
  96.  PD> correct name doing this, BTW!  :-)
  97.  
  98.  
  99. The answer was well received except for one small point:  it's a bit
  100. complicated, isn't it?  Well, I couldn't argue with that.  Andy McArdle
  101. suggested that this would be a candidate for a Plutonic utility.
  102.  
  103. And so was born PlutReject, a small utility to take a lot of the hard
  104. work out of the above steps, but still resulting in a renamed file in
  105. the inbound directory with the relevant FileNote to enable TrapDoor to
  106. resume transfer at the offset equal to the length of the file - in
  107. effect "cancelling" the incoming file.
  108.  
  109.  
  110.                             Using PlutReject
  111.                             ================
  112.  
  113. To save PlutReject a bit of work, the first thing you need to do is to
  114. put a copy of the file you don't want into the inbound directory.
  115.  
  116. Since the file is going to be safe, if you're running short of
  117. drivespace you can use your only copy if you like, and then move it back
  118. to where it belongs later.  Alternatively, use a copy in the inbound,
  119. and then you can delete it from there when the transfer is finished.
  120.  
  121. Once the file is in the inbound, you need to run PlutReject and tell
  122. PlutReject two things:
  123.  
  124. Firstly the full path and filename of the file.  (EG
  125. MAIL:Inbound/NodeDiff.L87).  If you CD to the inbound directory before
  126. running PlutReject, then just the filename itself will suffice (ie
  127. NodeDiff.L87).  You can use an assignment as well (eg IN:NodeDiff.L87)
  128.  
  129. PlutReject will complain if it can't find this file, and exit.
  130.  
  131. Secondly you need to tell PlutReject the node number of the system
  132. sending you the file.  If this is in zone 3, you may omit the zone.  If
  133. this is a point zero (ie a BBS, not a point), you can omit the point
  134. number.  So, to PlutReject these numbers mean the same thing:
  135. 3:622/401.0, 3:622/401, 622/401 and 622/401.0
  136.  
  137. This number has to be the PRIMARY address of the system sending you the
  138. file - !NOT! one of the system's AKAs.  You could be in for a shock if
  139. the system is on a rotary group for instance and presents a different
  140. primary node number on your next call.  Unfortunately there's not much
  141. we can do about that...
  142.  
  143. The node number must be in a valid fido node number format.  If not,
  144. PlutReject will complain and again, exit.
  145.  
  146. [Don't forget you MUST specify the zone if it's not in Zone 3]
  147.  
  148. The file you are receiving must match exactly with the length of the
  149. file you already have.  If it's out by as much as 1 byte, TrapDoor will
  150. think this is a different file, and PlutReject won't work as you expect
  151. it.  You could always adjust the length of the dummy file you have to
  152. match what the system is sending you if this causes a problem.  In this
  153. case, I'd recommend the dummy file in your inbound is a COPY of the
  154. original file :-)
  155.  
  156. Also, this will only work if the other end supports transfer resuming
  157. (virtually ALL systems do these days under a Zmodem derivative, eg
  158. ZedZap, TrapZap, etc)
  159.  
  160.  
  161.                                 Examples
  162.                                 ========
  163.  
  164. 1.> PlutReject Mail:Inbound/NodeDiff.L87 3:711/501
  165.  
  166. 1.> PlutReject IN:NodeDiff.L87 711/501
  167.  
  168. 1.> CD Mail:Inbound
  169. 1.> PlutReject NodeDiff.L87 3:711/501.0
  170.  
  171.  
  172.  
  173.                                 Test Run
  174.                                 ========
  175.  
  176. To test this out, I sent away a freq for a NodeDiff I already have.
  177. Firstly I used a directory utility to whip a copy over into the inbound.
  178.  
  179. I then ran PlutReject using one of the above examples, and called
  180. 3:711/501.  The TrapDoor log went like so (I sent and picked up a bit of
  181. mail during this test call, but I've cut out those lines):
  182.  
  183.  
  184. + 16-Oct-94 15:12:42  Calling Sentry's Shadow (3:711/501.0)
  185. ~ 16-Oct-94 15:13:05  CONNECT 12000/REL
  186. : 16-Oct-94 15:13:18   Name: Sentry's Shadow (3:711/501.0)
  187. : 16-Oct-94 15:13:18  Sysop: Trev Roydhouse
  188. : 16-Oct-94 15:13:18  Using: BinkleyTerm 2.59
  189. : 16-Oct-94 15:13:18  Offer: WaZoo FReqs ZedZap ArcMail 
  190. : 16-Oct-94 15:13:19  TrxID: 2ea14302
  191. * 16-Oct-94 15:13:19  Password-protected session
  192. = 16-Oct-94 15:13:19  Protocol: WaZoo/ZedZap
  193.  
  194. | 16-Oct-94 15:13:31  Sending 02c701f5.req (14 bytes)
  195. | 16-Oct-94 15:13:32  Took 0:00, Cps: 23, Efficiency: 1%
  196. | 16-Oct-94 15:13:32  Sent 02c701f5.req (14 bytes) successful
  197.  
  198. | 16-Oct-94 15:15:30  Receiving nodediff.l87 (65245 bytes)
  199. | 16-Oct-94 15:15:30  Resuming transfer from offset 65245
  200. | 16-Oct-94 15:15:31  Took 0:00, Cps: 0, Efficiency: 0%
  201. | 16-Oct-94 15:15:31  Received nodediff.l87 (65245 bytes) successful
  202.  
  203. = 16-Oct-94 15:15:42  Session connect time 2:36, cost 0.31
  204. ~ 16-Oct-94 15:15:42  Hanging up modem
  205.  
  206.  
  207. So as you can see, rather than taking some time to receive the file,
  208. this takes only 1 second, saving a substantial amount of transfer time
  209. receiving a file you already have!
  210.  
  211.  
  212.                               Limitations
  213.                               ===========
  214.  
  215. This will NOT work if the file you are receiving has spaces in it.  DO
  216. NOT USE INVERTED COMMAS in the arguments - we don't parse them at all.
  217.  
  218.  
  219.                                 Remember
  220.                                 ========
  221.  
  222. The dummy file in your inbound directory will be renamed back to the
  223. proper filename after TrapDoor calls back.  Don't forget to clean the
  224. directory up by copying the file back to where it belongs or deleting
  225. it.
  226.  
  227.  
  228.                        Distribution and Politics
  229.                        =========================
  230.  
  231. The PlutReject archive currently consists of these files:
  232.  
  233.         PlutReject                Executable
  234.         PlutReject.doc            This file
  235.         PlutReject.lst            GFABASIC Source (ascii)
  236.  
  237. It may NEVER be distributed without all the above files being present in
  238. the distribution copy.  No charge over and above a small copying fee may
  239. ever be levied on the distribution of the program.
  240.  
  241. All copyrights are retained by the author.  If you use any part of the
  242. source in other programs, acknowledgement must be given.
  243.  
  244. The liability of the author for any damages caused by this program is
  245. limited to the amount the user has paid directly to the author for the
  246. right to use the software (ie nil). Claims for amounts greater than this
  247. will be refused.
  248.  
  249. The author can be contacted:
  250.  
  251. Peter Deane
  252.  
  253. FidoNet:   3:622/401        Postal: PO Box 228
  254. GlobalNet: 54:6101/401              Swansea  NSW  2281
  255. AmigaNet:  41:200/401               AUSTRALIA
  256.  
  257. BBS:    from O/S   +61-49-72-1647
  258. (24hrs) from Aust  (049) 72-1647
  259.  
  260.             ------------------------------------------------
  261.  
  262.